ETSITS102 539V1.3.1 



(2010-04) 



Technical Specification 



Digital Video Broadcasting (DVB); 

Carriage of Broadband Content Guide (BCG) 

information over Internet Protocol (IP) 





EBU-UER 



DJ3 

Digital Video 
Broadcasting 





ETSI TS 102 539 V1.3.1 (2010-04) 



Reference 



RTS/JTC-DVB-280 
Keywords 



broadcasting, content, digital, DVB, IP, TV, video 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2010. 

© European Broadcasting Union 2010. 

All rights reserved. 

DECT"^", PLUGTESTS"^", UMTS™, TIPHON"^", the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM loco are Trade Marks reaistered and owned bv the GSM Association. 

ETSI 



ETSI TS 102 539 V1.3.1 (2010-04) 



Contents 



Intellectual Property Rights 5 

Foreword 5 

1 Scope 6 

2 References 6 

2.1 Normative references 6 

2.2 Informative references 7 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 8 

4 Delivery of BCG data 9 

4.1 Container-Based Delivery 9 

4.1.1 Definitions 9 

4.1.1.1 Container 9 

4.1.1.2 Compression wrapper 9 

4.1.1.3 Data Delivery Unit 10 

4.1.2 Transport 10 

4.1.2.1 SD&S Information Data Types 10 

4.1.2.2 Transport mechanisms 10 

4.1.2.2.1 Protocol for Multicast Delivery of BCGs 10 

4.1.2.2.2 Protocol for Unicast Delivery of BCGs 11 

4.2 Query mechanism 11 

5 Content Resolution 12 

5.1 RNT (Resolution Provider Notification Table) 12 

5.2 RAR over IP descriptor 12 

5.3 CRI structures 12 

6 Profile ofTV-Anytime Metadata for BCG 13 

6.1 Introduction 13 

6.2 Void 13 

6.3 Schedule fragment 13 

6.4 Servicelnformation fragment 13 

6.5 OnDemandProgram fragment 13 

6.6 Purchase Information fragment 14 

6.7 PushDownloadProgram fragment 14 

7 TV- Anytime Fragments 15 

7.1 Fragment encapsulation 15 

7.2 Fragment encoding 15 

7.3 DVB-TVA-init message 15 

7.4 TVAMain fragment 15 

8 Locator and Program URL usage 15 

8.1 Live Media Broadcast (LMB) 15 

8.2 Media Broadcast with Trick Modes (MBwTM) 16 

8.3 Content on Demand (CoD) 16 

8.4 Pull Content Download 17 

8.5 Push Content Download 17 

Annex A (normative) : URI schemes 18 

A.l DVB-MCAST URI scheme for DVB services in a MPEG-2 TS delivered over IP Multicast 18 

A.2 RTSP URI scheme for DVB services in a MPEG-2 TS delivered over IP sessions controlled by 

RTSP 19 



£75/ 



4 ETSI TS 1 02 539 V1 .3.1 (201 0-04) 

Annex B (informative) : Bibliography 20 

History 21 



£75/ 



ETSI TS 102 539 V1.3.1 (2010-04) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Digital Video Broadcasting Project (DVB) is an industry-led consortium of broadcasters, manufacturers, network 
operators, software developers, regulatory bodies, content owners and others committed to designing global standards 
for the delivery of digital television and data services. DVB fosters market driven solutions that meet the needs and 
economic circumstances of broadcast industry stakeholders and consumers. DVB standards cover all aspects of digital 
television from transmission through interfacing, conditional access and interactivity for digital video, audio and data. 
The consortium came together in 1993 to provide global standardisation, interoperability and future proof 
specifications. 
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Scope 



The present document specifies the signalUng and the transport of TV- Anytime information over an always-on 
bi-directional IP network. The specification allows for metadata describing Live Media Broadcast, Content on Demand 
and Content Download Services delivered over any type of network using DVB specifications (e.g. DVB-T, DVB-S, 
DVB-IPTV). It can be used to develop a Broadband Content Guide, i.e. a content guide that is delivered over an 
always-on bi-directional IP network. 

The present document is an addendum to TS 102 034 [4], 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 

cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were vaUd at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI TS 102 323: "Digital Video Broadcasting (DVB); Carriage and signalHng of TV-Anytime 

information in DVB transport streams". 

[2] ETSI TS 102 822-3-2: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 2: System aspects in a 
uni -directional environment". 

[3] ETSI TS 102 822-3-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 3: Metadata; Sub-part 1: Phase 1 - Metadata 
schemas". 

[4] ETSI TS 102 034: "Digital Video Broadcasting (DVB) Transport of MPEG-2 TS Based DVB 

Services over IP Based Networks". 

[5] IETF RFC 1950: "ZLIB Compressed Data Format Specification version 3.3". 

[6] IETF RFC 1951: "DEFLATE Compressed Data Format Specification version 1.3". 

[7] ETSI TS 102 822-6-1: "Broadcast and On-line Services: Search, select, and rightful use of content 

on personal storage systems ("TV-Anytime"); Part 6: Delivery of metadata over a bi-directional 
network; Sub-part 1: Service and transport". 

[8] W3C Note (08 May 2000): "Simple Object Access Protocol (SOAP) 1.1". 
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[9] ISO/IEC 13818-1: "Information technology - Generic coding of moving pictures and associated 

audio information: Systems". 

[10] ISO/IEC 23001-1: "Information technology - MPEG systems technologies - Part 1: Binary MPEG 

format for XML". 

[11] ETSI EN 300 468: "Digital Video Broadcasting (DVB); Specification for Service Information (SI) 

in DVB systems". 

[12] IETF RFC 2326: "Real Time Streaming Protocol (RTSP)". 

[13] Void. 

[14] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[15] ETSI TS 102 851: "Digital Video Broadcasting (DVB); Uniform Resource Identifiers (URI) for 

DVB Systems". 

[16] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax". 

[17] IETF RFC 4907: "Architectural ImpHcations of Link Indications". 

2.2 Informative references 

The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Content Download Service (CDS): service that provides download delivery of content items to the local storage of the 
HNED 

NOTE: The consumption is independent of the delivery. 

Content on Demand (CoD): program provided at the request of the end user for direct consumption (real-time 

streaming) 

content provider: entity that owns or is licensed to sell content or content assets 

Delivery Network (DN): network connecting the Delivery Network Gateway (DNG) and service providers 

Delivery Network Gateway (DNG): device that is connected to one or multiple delivery networks and one or multiple 
home network segments 

DVB-IPTV service: one or more programmes under the control of a service provider delivered over IP 

NOTE: The programmes can be made available either as part of a schedule or on demand and either for direct 
consumption (Live Media Broadcast or Content on Demand Services) or for local storage (CDSs). 

event: grouping of elementary broadcast data streams with a defined start and end time belonging to a common service 

EXAMPLE: First half of a football match. News Flash, first part of an entertainment show. 

Home Network End Device (HNED): device that is connected to a home network and which typically terminates the 
IP based information flow (sender or receiver side) 
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package: collection of DVB services marketed as a single entity 

program: collection of program elements 

NOTE: Program elements may be elementary streams. Program elements need not have any defined time base; 
those that do, have a common time base and are intended for synchronized presentation. Taken from 
ISO/IEC 13818-1 [9]. 

Service Provider (SP): entity providing a service to the end-user 

NOTE: In the context of the present document, SP will mean a Service Provider providing DVB-IPTV services. 

SP offering: set of streams or services a Service Provider proposes to the end-user 

Transport Stream: data structure defined in ISO/IEC 13818-1 [9] 

TS Full SI: transport stream with embedded service information as defined by DVB in EN 300 468 [11] with the 
exception of the network information table NIT 

NOTE: This table may be omitted as it has no meaning in the context of IP services. 

TS - Optional SI: transport stream with MPEG PSI (PAT and PMT tables) as defined in ISO/IEC 13818-1 [9] 

NOTE: All other MPEG-2 and DVB tables are optional. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

BCG Broadband Content Guide 

BiM Binary format for Multimedia description streams 

CDS Content Download Service 

CoD Content on Demand 

CRI Content Referencing Information 

CRID Content Reference IDentifier 

DNG Delivery Network Gateway 

DVB Digital Video Broadcasting 

DVBSTP DVB SD&S Transport Protocol 

HNED Home Network End Device 

HTTP Hyper Text Transfer Protocol 

IMI Instant Metadata Identifier 

IP Internet Protocol 

IPI Internet Protocol Infrastructure 

IPTV Internet Protocol TV 

LMB Live Media Broadcast 

MBwTM Media Broadcast with Trick Modes 

MPEG Moving Pictures Expert Group 

NIT Network Information Table 

PAT Program Association Table 

PMT Program Map Table 

PSI Program Specific Information 

RAR Resolving Authority Record 

RNT RAR Notification Table 

RTP Real-time Transport Protocol 

RTSP Real Time Streaming Protocol 

SD&S Service Discovery and Selection 

SOAP Simple Object Access Protocol 

SP Service Provider 

SSM Source Specific Multicast 

UDP User Datagram Protocol 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

XML extensible Markup Language 
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4 Delivery of BCG data 

BCG data may be delivered in the following ways: 

• Container-based: 

via IP multicast (i.e. pushed); 
via IP unicast (i.e. pulled). 

• Query: 

via IP unicast. 

The IPI-1 interface as defined in TS 102 034 [4] shall support the container-based mechanism, both via multicast and 
unicast. It may additionally support the query mechanism. 

On all networks there shall be at least one BCG provider that supports the container based download mechanism. 
Additionally, this provider may support the query mechanism. 

For clarification, the query mechanism is optional for both Service Providers and HNEDs. 

The container based download mechanism uses the Data Delivery Unit, as specified in clause 4.1.1.3, delivered via the 
mechanisms specified in clause 4.2. 

The query mechanism is specified in clause 4.3. 

4.1 Container-Based Delivery 
4.1.1 Definitions 
4.1.1.1 Container 

A container shall carry either a RNT, one or more CRI structures or metadata. Each container is distinguished by a 
unique identifier, which is the container_id. Table 1 shows the clauses in the present document where the container 
format, according to each type of data carried, is defined. 

Table 1 : Container Format Definitions 



Type of data carried 


Container Format Definition 


RNT 


Clause 5.1 in the present document 


CRI structures 


TS 102 323 [1], clause 7.3.1.3 


Metadata 


TS 102 323 [1], clause 9.3 



The type of data that the container carries determines the scope and format of the structure values. 

4.1 .1 .2 Compression wrapper 

The compression_wrapper allows a container to be carried in a compressed or uncompressed format. The syntax of the 
compression_wrapper is defined in table 21, clause 7.3.1.5 of TS 102 323 [1]. The compression_wrapper shall always 
be present, whether or not the container is compressed. 

The semantics of the fields of table 21, clause 7.3.1.5 of TS 102 323 [1] are modified as follows: 

• container(): See clause 4.1.1.1 for the definition of the container structure. 

NOTE: This definition differs from TS 102 323 [1], where the compression wrapper may contain CRI structures 
only. 
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• compression_structure: This shall contain a container (see clause 4.1.1.1) encoded as a Zlib stream 

(as defined in RFC 1950 [5]). When present, the Zlib stream shall have its compression method nibble set to 
"1000", indicating use of the Deflate compression algorithm as specified in RFC 1951 [6]. 

4.1.1.3 Data Delivery Unit 

A Data Delivery Unit is a container, as defined in clause 4.1.1.1, within a compression wrapper as defined in 
clause 4.1.1.2. 

4.1.2 Transport 

4.1 .2.1 SD&S Information Data Types 

In addition to the Payload ID values defined in TS 102 034 [4], table 1, clause 5.2.2.1, the values defined in table 2 shall 
be used for the BCG Data Delivery Units. 

Table 2: BCG Payload ID values 



Payload ID value 


Payload type carried 


OxAl 


DVB-TV A-init message (clause 7.3 in the present document) 


0xA2 


TVAMain fragment (clause 7.4 in the present document) 


0xA3 


TV-Anytime metadata data container (clause 9.2.2 of TS 102 323 [1]), value "d" in table 50) 


0xA4 


TV-Anytime metadata index container (clause 9.2.2 of TS 102 323 [1], value "i" in table 50) 


0xA5 


Both TV-Anytime metadata data and index container (clause 9.2.2 of TS 102 323 [1], 
value "b" in table 50) 


0xA6 


RNT (clause 5.1 in the present document) 


0xA7 


CRl structure (clause 5.3 in the present document) 


0xA8-0xAF 


Reserved 



4.1 .2.2 Transport mechanisms 

This clause specifies the protocols that are used to transport the BCG information. Two mechanisms are defined, one 
for multicast and one for unicast. 

The protocol DVB SD&S Transport Protocol (DVBSTP), as specified in clause 5.4.1 of TS 102 034 [4], shall be used 
to transport BCG information over multicast. 

The protocol HTTP [14] shall be used to transport BCG information over unicast. 

The two transport mechanisms shall be interchangeable in all steps and carry the same content encoded in the same 
way. 

4.1 .2.2.1 Protocol for Multicast Delivery of BCGs 

For the push model delivery of BCGs, the protocol DVBSTP, as defined in TS 102 034 [4], clause 5.4.1.2, shall be used 
to transmit Data Delivery Units, as defined in clause 4.1.1.3 of the present document. Additional semantics are defined 
for the following fields: 

• Payload ID: The Payload ID shall be encoded as specified in table 2 of the present document. 

• Segment ID: If the Payload ID value is OxA3, 0xA4 or OxA5, then this field has the semantics of the 
container_id defined in TS 102 822-3-2 [2], clause 4.5.1.3. If the Payload ID value is 0xA7 then this field has 
the semantics of the container_id defined in TS 102 323 [1], clause 7.3.1.1. 

• Segment Version: If the Payload ID value is OxA3, 0xA4 or OxA5, then this field has the semantics of a 
container version identifier defined in TS 102 822-3-2 [2], clause 4.5.2. 

• Compression (Compr): Additional compression values are defined in table 3. 
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The field value of "001" is used to signal the encoding defined in the present document, which will be either BiM [10] 
for XML data or a specific binary representation for non XML data (RNT, CRI, etc.). Use of other values in the 
compression field is not defined. 

Table 3: Additional Compression Values 



Compression value 


Meaning 


Total Segment Size Meaning 


001 


Either BiM or tlie specific binary 
representation defined in the 
present document 


Transmitted Size 



4.1.2.2.2 



Protocol for Unicast Delivery of BCGs 



In the pull model of delivery of BCGs, the HTTP [14] protocol shall be used for all communication between the HNED 
and the BCG server(s). 

When the HNED requests BCG information, it shall use the format defined in TS 102 034 [4], clause 5.4.2. The 
Payload ID values used shall be as defined in table 2 of the present document. The segmentID values shall have the 
same semantics as defined in TS 102 034 [4], clause 5.4.1.2. The BCG server(s) shall return Data Delivery Units, as 
defined in clause 4. 1 . 1 .3 of the present document. 

When the HNED requests BCG information, it shall use the following format: 

"GET /dvb/sdns/bcg_request HTTP/1.1" CRLF 
"Host: " host CRLF 

The bcg_request shall comply with the following format: 

bcg_request = bcg?Payload="PayloadId"&;Segment = "SegmentItem" 

where: 

Payloadid = 2 HEXDIG; any hex number from 00 to ff 
Segmentid = 4 HEXDIG;any hex number from 0000 to ffff 
Segmentltem = Segmentid 0*1 {' S;Version= 'Vers ionNumber) 

Segmentltem is a Segmentid with an optional field for the version number. 

VersionNumber = 2 HEXDIG; any hex number from 00 to ff 

For example, the following request can be constructed to request the index list structure (see TS 102 323 [1], 
clause 9.2.2): 

"GET /dvb/sdns/bcg?Payload=A4&Segment=0000 HTTP/1.1" CRLF 
"Host: " host CRLF 

The HTTP headers returned with the data shall be: 

Content-encoding : x-dvb-bcg-ip 

4.2 Query mechanism 

The query mechanism for BCG acquisition is described in this clause. 

When the query mechanism is used, it shall be implemented according to TS 102 822-6-1 [7] and the requirements 
described in this clause. TS 102 822-6-1 [7] describes four SOAP methods. The version of SOAP [8] used shall 
be 1.1. 
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Table 4 shows the status of these methods within the present document. 

Table 4: Requirements for Service Providers and l-INEDs relating to 
SOAP methods as defined in TS 102 822-6-1 [7] 





Service Provider 


HNED 


get Data 


M 


M 


describe Get Data 


M 


M 


submit Data 








describe_Subnnit_Data 


(if submit_Data not supported) 
IVI (if submit_Data supported) 






5 Content Resolution 

Content resolution is performed as in TS 102 323 [1], with the following additional constraints. 

5.1 RNT (Resolution Provider Notification Table) 

This table shall be carried inside a Data Delivery Unit, as defined in clause 4.1.1.3 of the present document. 

The syntax and semantics of table 1 of clause 5.2.2 of TS 102 323 [1] shall be used, but deleting all the fields preceding 
the common_descriptors_length field, except the last 4 reserved bits. This removes all references to table sections, 
context_id and context_id_type, which are not relevant to the present document 



5.2 BAR over IP descriptor 



The RAR over IP descriptor defined in TS 102 323 [1], clause 5.3.6 shall have the following additional semantics: 

• urljength: The length of the URL. A length of can be used to indicate that the CRI structures shall be 
transmitted via the URL that is currently used. 

• url_char: If present, this field shall contain a URL. The rules governing the encoding of an URL shall be as 
defined in clause 6.2 of TS 102 323 [1]. 

5.3 CRI structures 

CRl structures are used to resolve a CRID into one or more locator(s) or CRID(s). 

The format of CRI structures defined in TS 102 323 [1], clause 7.3.1.3 shall be used. 

The URI compliant string, DVB binary locator. Scheduled decomposed binary locator. On-demand decomposed binary 
locator and Extended On-demand decomposed binary locator shall be supported, as defined in TS 102 323 [1], 
clause 7.3.2.3. The specific syntax and usage of the locator for a DVB-IPTV service shall be as defined in clause 8 of 
the present document. 

This structure shall be carried inside a Data Delivery Unit, as defined in clause 4.1.1.3 of the present document. 

The container carrying the cri_index structure, which is the first structure required by the receiver, shall have its 
Segment ID set to 0x0000, as specified by TS 102 323 [1], clause 7.3.1.1. 
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6 Profile of TV-Anytime Metadata for BCG 

6.1 Introduction 

TS 102 822-3-2 [2] provides several options for how to structure descriptions of program, group and location 
information. The profile as specified in TS 102 323 [1], clause 8 shall apply for the BCG. Table 45 of [1] lists all the 
supported metadata fragments. BCG specific usage of some of the fragments is defined in the clauses below. 

NOTE: The present document does not provide any profiling for metadata delivered by other means. 

6.2 Void 



6.3 Schedule fragment 



The ProgramURL element may be present, to provide an indication of the expected Live Media Broadcast service 
location as defined in clause 8. 



6.4 Servicelnformation fragment 



If an optional field is not specified in the BCG Servicelnformation Fragment of a Live Media Broadcast service, the 
corresponding information shall be inferred from the SD&S Broadcast Discovery Record information of that service if 
provided. If an optional field is specified both in the BCG and the SD&S information, then the field of the BCG shall be 
used. 

The reference between the Servicelnformation Fragment and the SD&S Broadcast Discovery Record is provided by the 
serviceld of the Servicelnformation fragment which shall be equal to the textual identifier, the concatenated 
ServiceName and service provider DomainName of the corresponding SD&S Broadcast Discovery Record, as defined 
in clauses 5.2.1.2 and 5.2.6.2 of TS 102 034 [4]. This ensures a unique mapping between SD&S and BCG records for a 
service. For instance, if the ServiceName of a service from the Service Provider "sport-provider.com" is 
"extreme-sport" in SD&S, the serviceld in BCG shall also be "extreme-sport.sport-provider.com". 

The Name element (mandatory at BCG level) may be an empty element, in which case it shall be inferred from the 
SD&S information of that service, i.e. the SI Name defined in clause 5.2.6.2.2 of TS 102 034 [4]. If the Name element 
(mandatory at BCG level) is filled, then this field shall be used. 

If the Logo element is present, it shall contain a URL that points to an image file. 

6.5 OnDemandProgram fragment 

If the Instance Description field is present, its elements shall override the matching elements defined in the 
corresponding Program Information fragment. 

The DeliveryMode, PublishedDuration, StartOfAvailability, EndOfAvailability, FirstAvailability, LastAvailability, 
Immediate Viewing, Content version, ExpiryTime and EarlyPlayout elements in the OnDemandProgram element are 
optional. If they are not present the default values defined in table 5 shall be used. 
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Table 5: Default values for onDemandProgram elements 



Element 


Default values 


DeliveryMode 


Streaming 


PublishedDuration 


The value of the Program Information fragment, if present, else undefined 


StartOfAvailability 


Now 


EndOfAvailability 


Indefinitely 


FirstAvailability 


Undefined 


LastAvailability 


Undefined 


ImmediateViewing 


False 


ContentVersion 





Expiry Time 


Indefinitely 


EarlyPlayout 


False 



The Program element shall be present and shall contain a CRID that can be found in the ProgramlnformationTable and 
this CRID should also be present in the CRI. 

The ProgramURL element may be present to provide the location as defined in clause 8. 

The CRI shall be considered the authoritative source of CRID to location information. 

The InstanceMetadatald (IMI) may be present and when present the same IMI shall be available in the CRI. 

NOTE: The CRI can return a "not yet resolvable" flag in case the location is not yet available, but will be 
provided later. In this case it is recommended that the "StartOfAvailability" element is sent. 



6.6 Purchase Information fragment 



The Purchaselnformation fragment shall be defined as in TS 102 822-3-2 [2], clause 4.3.1.10 and TS 102 822-3-1 [3], 
clause 6.3.4 (complex type PurchaseltemType), with the following recommendations: 

• A purchaseList element shall contain at least one Purchaseltem or PurchaseldRef. 

• Exactly one of the price attributes unit or currency shall be present. 

• If a PurchaseldRef is used, it shall contain a reference to a Purchase element that can be found in the 
TransactionlnformationTable. 

If the PricingServerURL is used, the returned information shall be a Data Delivery Unit containing a Pricinglnformation 
fragment. 

6.7 PushDownloadProgram fragment 

If the Instance Description field is present, its elements shall override the matching elements defined in the 
corresponding Program Information fragment. 

The PublishedDuration, StartOfAvailability, EndOfAvailability, Content version and ExpiryTime elements in the 
OnDemandProgram element are optional. If they are not present the default values defined in table 6 shall be used. 

Table 6: Default values for PushDownloadProgram elements 



Element 


Default values 


PublishedDuration 


The value of the Program Information fragment, if present, else undefined 


StartOfAvailability 


Now 


EndOfAvailability 


Indefinitely 


ContentVersion 





ExpiryTime 


Indefinitely 



The ProgramURL element shall be present to provide the location of the download session description as defined in 
clause 8. CRID resolution shall not be performed. 
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7 TV-Anytime Fragments 

7.1 Fragment encapsulation 

TV-Anytime fragments shall be delivered in Data Delivery Units, as defined in clause 4.1.1.3 of the present document, 
i.e. they shall be carried in containers within a compression wrapper and dehvered either using HTTP or DVBSTP. 

7.2 Fragment encoding 

TV-Anytime fragments shall be encoded with BiM [10], as defined in TS 102 323 [1], clause 9.4. 



7.3 DVB-TVA-init message 



The DVB-TVA-init message for the decoding of the TVA metadata fragment stream shall be conformant to the DVB 
profile of the TVA MPEG-7 profile as defined in TS 102 323 [1], clause 9.4.2.1. 

The DVB-TVA-init message shall be delivered, as defined in table 2 of the present document, using the Payload ID 
value OxAl. 



7.4 TVAIVIain fragment 



The TVAMain fragment, defined in TS 102 822-3-2 [2] contains the initial description of a TV-Anytime document. The 
transmission of this fragment is optional, as specified in TS 102 323 [1], clause 9.4.2.2. 

If transmitted, the TVAMain fragment shall be delivered as defined in table 2 of the present document, using the 
Payload ID value 0xA2. 

If not transmitted, the default TVMain fragment shall be used by the HNED, as specified in TS 102 323 [1], 
clause 9.4.2.2. 



8 Locator and Program URL usage 

Locators as part of CRI, and ProgramURLs as part of instance description metadata are used to reference DVB-IPTV 
services from the BCG. This clause defines the locator and ProgramURL formats for the different DVB-IPTV services 
defined in TS 102 034 [4]. 

8.1 Live IVIedia Broadcast (LIVIB) 

LMB services can be referenced via: 

• the ProgramURL of the ScheduleEventType or BroadcastEventType instance metadata; 

• the URI compliant string locator; 

• the DVB binary locator; or 

• the Scheduled decomposed binary locator. 

The URI references to LMB services (as used by ProgramURL, URI compliant string locator and Scheduled 
decomposed binary locator) shall support: 

• the DVB URI scheme as defined in TS 102 851 [15], clause 6.4; 

• the D VB-MCAST URI scheme as defined in clause A. 1 ; or 

• the RTSP URI scheme as defined in clause A. 2. 
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For referencing a LMB service announced via a SD&S BroadcastDiscovery record as defined in TS 102 034 [4], 
clause 5.2.6.2 one of the following reference schemes shall be used: 

• the DVB triplet information (original network ID, transport stream ID and service ID); or 

• the textual service identifier (concatenated service name and domain name); 

of the broadcast channel as provided in the SD&S BroadcastDiscovery record. 

DVB triplet information can be provided by the DVB Binary locator or the DVB URL Textual service identifier 
information can be provided by the DVB URI. 

8.2 Media Broadcast with Trick IVIodes (IVIBwTIVI) 

MBwTM services can be referenced: 

• via the ProgramURL of the ScheduleEventType or BroadcastEventType instance metadata; 

• the URI compliant string locator; 

• the DVB binary locator; or 

• the Scheduled decomposed binary locator. 

The URI references to MBwTM services (as used by ProgramURL, URI compliant string locator and Scheduled 
decomposed binary locator) shall support: 

• the DVB URI scheme as defined in TS 102 851 [15], clause 6.4; or 

• the RTSP URI scheme as defined in clause A.2. 

For referencing a MBwTM service announced via a SD&S BroadcastDiscovery record as defined in TS 102 034 [4], 
clause 5.2.6.2 one of the following reference schemes shall be used: 

• the DVB triplet information (original network ID, transport stream ID and service ID); or 

• the textual service identifier (concatenated service name and domain name); 

of the broadcast channel as provided in the SD&S BroadcastDiscovery record. 

DVB triplet information can be provided by the DVB Binary locator or the DVB URI. Textual service identifier 
information can be provided by the DVB URL 

8.3 Content on Demand (CoD) 

Streaming CoD services can be referenced via: 

• the ProgramURL of the OnDemandProgramType instance metadata; 

• the URI compliant string locator; 

• the On-demand decomposed binary locator; or 

• the Extended On-demand decomposed binary locator. 

The URI references to streaming CoD services (as used by ProgramURL, URI compliant string locator. On-demand 
decomposed binary locator and Extended On-demand decomposed binary locator) shall support the RTSP URI scheme 
as defined in clause A. 2. 
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8.4 Pull Content Download 

Pull Content download services can be referenced via: 

• the ProgramURL of the OnDemandProgramType instance metadata; 

• the URI compliant string locator; or 

• the Extended On-demand decomposed binary locator. 

The URI references to Pull Content download services (used by ProgramURL, URI compliant string locator and 
Extended On-demand decomposed binary locator) shall support the URI schemes for referencing download session 
descriptions as defined in TS 102 034 [4], clause 10.3.2. 

8.5 Push Content Download 

Push Content download services can be referenced via: 

• the ProgramURL of the PushDownloadProgramType instance metadata. 

CRID resolution and CRI locators are not supported for Push Content download services. 

The URI reference to Push Content download services (used by ProgramURL) shall support the URI schemes for 
referencing download session descriptions as defined in TS 102 034 [4], clause 10.3.2. 
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Annex A (normative): 
URI schemes 



This annex describes DVB specific URI schemes and scheme extensions used in locators and ProgramURLs as defined 
in clause 8. 



A.1 DVB-MCAST URI scheme for DVB services in a 
l\/IPEG-2 TS delivered over IP Multicast 

The basic DVB-MCAST URI scheme defined in TS 102 034 [4], clause G.3.1 is extended in order to reference specific 
program events in a MPEG-2 transport stream delivered over IP multicast. 

The MPEG-2 transport stream can be delivered directly via UDP or via UDP and RTP as defined in TS 102 034 [4], 
clause 7. 1 . The transport is indicated by the payload parameter. A payload type of 'mp2t' indicates direct UDP transport 
while a payload type of 'mp2t/rtp' indicates a RTP over UDP transport. 

If only the multicast address information (source host, multicast address and port) are provided the MPEG-2 transport 
stream is referenced without providing information on specific services within the transport stream. The dvb-service 
parameter set provides information on the specific DVB service within the MPEG-2 transport stream and reuses syntax 
structures from the DVB URI defined in TS 102 851 [15]. If dvb-service parameters are not provided the HNED shall 
decide from the context in which the URI is used and the DVB Service Information (DVB-SI) [11] within the transport 
stream which components of the transport stream it has to access. 

The URI scheme is defined as follows: 

"dvb-mcast : //" [ src-host "@" ] mcast-addr ":" port "?payload=" { "mp2t" | "mp2t/rtp" ) ["&;dvb-service=" 
[service_id ["." component_set ["$"dvb_carousel_id] ] [dvb_event_constraint] ] [path-absolute]] 

src-liost = source liost {for source specific multicast) 

mcast-addr = multicast address 

port = port number 

service_id = as defined in TS 102 851 [15], clause 6.1 

component_set = as defined in TS 102 851 [15] , clause 6.1 

dvb_carousel_id = as defined in TS 102 851 [15], clause 6.1 

dvb_event_constraint = as defined in TS 102 851 [15] , clause 6.4.1 

patli-absolute = as defined in RFC 3986 [16], for tlie usage see TS 102 851 [15], clause 6.2 

The mcast-addr shall specify the multicast address the client has to join and the port shall specify the UDP destination 
port where to receive the multicast data stream. 

The src-host is an optional syntax element referring to the unicast IP address of the source of the multicast data. This is 
only meaningful in case Source Specific Multicast (SSM) as defined in RFC 4907 [17] is supported. 
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A.2 RTSP URI scheme for DVB services in a l\/IPEG-2 
TS delivered over IP sessions controlled by RTSP 

The RTSP URI as defined in RFC2326 [12] is extended in order to reference specific components (e.g. services, 
program events) in a MPEG-2 transport stream delivered over IP and controlled by RTSP [12]. 

The URI scheme is defined as follows: 

"rtsp://" host [":" port] [path-absolute] ["#dvb-service=" [service_id [" . "component_set 
["$"dvb_carousel_id] ] [dvb_event_constraint] ] [path-absolute] ] 

host = host domain name or IP address as defined in RFC3986 [16] 

port = port number as defined in RFC3986 [16] 

path-absolute = absolute path as defined in RFC3986 [16] ; for the usage within the 

dvb-service fragment part see TS 102 851 [15] , clause 6.2 

service_id = as defined in TS 102 851 [15], clause 6.1 

component_set = as defined in TS 102 851 [15] , clause 6.1 

dvb_carousel_id = as defined in TS 102 851 [15], clause 6.1 

dvb_event_constraint = as defined in TS 102 851 [15] , clause 6.4.1 

The host, port and path-absolute parts of the URI reference a MPEG-2 transport stream. These are the standard parts of 
a RTSP URI and shall be used by RTSP to setup and control the MPEG-2 transport stream delivery session as defined 
in TS 102 034 [4], clause 6. 

For enabling the reference to specific components within the received (and possibly stored) MPEG-2 transport stream, 
the usage of DVB service specific parameters in the fragment part of the URI is specified above. These parameters 
reuse syntax structures from the DVB URI defined in TS 102 851 [15]. The fragment part of the URI is not used by 
RTSP and not sent from the HNED to the RTSP server for the MPEG-2 transport stream delivery session setup and 
control. It is only used by the HNED to access locally the specific component within the MPEG-2 transport. If DVB 
service specific parameters are not provided in the fragment part of the URI the HNED shall decide from the context in 
which the URI is used and the DVB Service Information (DVB-SI) [11] within the transport stream which components 
of the transport stream it has to access. 
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